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A method for programming a bus-compatible electronic 
motor vehicle controller that is equipped with at least one 
microcomputer to implement its control function and with 
ROM and RAM in order to accommodate and handle 
applications software required for the control function, and is 
also equipped with at least one bus protocol chip, the ROM 
being programmed such that the applications software 
communicates with a bus via the bus protocol chip and via a 
specific instruction and communications interface forming a 
first interface of the bus protocol chip. The method includes 
providing a second interface, which is independent of the bus 
protocol chip, and defining the second interface as a further, 
universal instruction and communications interface. The first 
and second interfaces are coupled with a driver module that 
is independent of the applications software and adapted to 
the bus protocol chip and has the properties of an adapter. 
The applications software are matched and aligned 
exclusively to the second interface with respect to the bus 
communication and the applications software is produced 
independently of the bus protocol chip. The applications 
software and the driver module are linked to one another by 
a link process. Program code is obtained as a result of the 
link process. The program code is stored such that the 
program code is resident in the ROM. 
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Prufungsantrag gem. § 44 PatG ist gestellt 

(§4) Verfahreh zur Prog rammie rung eines busfahigen elektronischen Kfz-Steuergerates 



(57) Ein Verfahren zur Programmierung eihes busfahigen elek- 
tronischen Kfz-Steuergerates wird beschrieben, Jetztwel- 
ches zur Realisierung seiner Steuerfunktion mit wenigstens 
einem Mikrorechner (und) mit ROM und RAM zur Aufnahme 
bzw. Abwicklung der fur die Steuerfunktion erforderlichen 
Applikationssoftware und des weiteren mit wenigstens 
einem Bus-Protokollchip ausgerustet ist, und wobei die 
Programmierung des ROMs in einer Weise geschieht, daS 
besagte Applikationssoftware uber den wenigstens einen 
Bus-Protokollchip und insoweit im Sinne einer ersten 
Schnittstelle uber dessen/deren spezifische Instruktions- 
und Kommunikationsoberflache(n) mit dem Bus kommuni- 
ziert. ErfindungsgemaS wird der wenigstens eine Bus-Proto- 
kollchip gegenuber der Applikationssoftware "verdeckt", 

1 _ indem eine zweite, universelle, vom/von Bus-Protokoll- 
chip(s) unabhangige Schnittstelle definiert wird, zwecks 
KoppJung dieser Schnittstelle mit der Instruktions- und 
Kommunikationsoberflache des/der Bus-Protokollchip(s) un- 
abhangig von der. Applikationssoftware ein auf den/die 
relevant en Bus-Protokollchip(s) zugeschnittenes Treiber- 
Modul mit Adaptereigenschaften erzeugt wird, die steuerge- 
ratespezifische Applikationssoftware ausschliefclich auf die 

^3 zweite Schnittstelle abgestimmt und ausgerichtet und inso- 
wait unabhangig.von dem/den Bus-Protokollchip(s) erzeugt 
wird, die von letzterem(n) unabhangige Applikationssoftwa- 
re und das applikationsunabhangige Treiber-Modul mittels 

iyyi eines Linkprozesses miteinander verknupft ... 
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Beschreibung 



Die Erfindung betrifft ein Verfahren zur Program- 
mierung eines busfahigen elektronischen Kfz-Steuerge- 
rates in einem Kraftfahrzeug nach der Gattung des An- 5 

spruchs 1. . . _ * 

Der vermehrte Einsatz elektrischer und msbesondere 
elektronisch gesteuerter Aktuatoren, Motoren und Ag- 
gregate in Kraftfahrzeugen macht eine immer umfang- 
reichere Verdrahtung erforderlich. Die steigende An- io 
zahl von Kontakten und Kabeln bedingt wachsenden 
Fertigungsaufwand, Platzprobleme innerhalb der Ka- 
rosserie und eine insgesamt sinkende Zuverlassigkeit, 
bei zunehmenden Kosten. Fehlersuchen werden immer 

zeitraubender. „^ T ,^ . 15 

Um hier Abhilfe zu schaffen, wurde das CAN (Cont- 
roller Area Network)-Konzept entwickelt Es handelt 
sich dabei um ein serielles Busnetzwerk mit einem spe- 
ziellen Dateniibertragungsprotokoll, in welches alle ent- 
sprechenden Komponenten eingebunden werden und 20 
welches eine Quasi- Echtzeitanwendung mit sehr hoher 
Betriebssicherheit erlaubt 

Im Rahmen dieses neuen Konzepts werden alle Steu- _ 
er- und Betriebsgerate, die in einem soichen Busnetz 
betrieben werden sollen, mit entsprechenden Hard- und 25 
Softwaremitteln ausgestattet, so daB sie sich dem Bus- 
protokoll gemaB verhalten und ohne gegenseitige Be- 
eintrachtigung angesprochen werden bzw. Daten oder 
Steuerbefehle vorzugsweise im Broadcast- Verfahren 
iiber das Netz verbreiten konnen. In der Praxis wird dies 30 
pro Steuergerat durch einen am Bus liegenden und die- 
sen bedienenden Bus-Protokollchip, im folgenden auch. 
CAN-Controller oder kurz CAN-Chip genannt, reah- 
siert, welcher mit dem/den jeweiligen hierfur entspre- 
chend programmierten Mikrorechner/n des Steuerge- 35 
rates, d. h. mit der spezifischen Applikation, kommuni- 
ziert 

Die Vielzahl von busrelevanten Steuergeraten m ei- 
nem Fahrzeug und die folgliche Beilieferung von unter- 
schiedlichen Herstellern hat demnach. zur Foige, daB 40 
vergleichbare Zugriffe bzw. Kommunikationsfunktio- 
nen der jeweils steuergeratespezifischen Applikations- 
sof tware auf den Bus je nach verwendetem CAN-Cont- 
roller von jedem Steuergeratehersteller separat gelost 
werden mussen und in der Praxis auch auf jeweils ande- 45 
re Weise gel6st werden. Dies hat nicht nur einen insge- >■ 
samt erheblichen Zeitaufwand fiir die jeweils individuel- 
le Programmierung zur Folge. Aus je nach Programmie- 
rung unterschiedlichen bzw. streuenden Durchgriffszei- 
ten von der Applikation uber den CAN-Controller auf 50 
den Bus konnen verdeckte Probleme z. B. beim Echt- 
zeitbetrieb einer groBen Zahl von Steuergeraten unter- 
schiedlicher Hersteller entsteheh, auch wenn alle Gera- 
te jeweils fur sich alleine genommen das Bus-Protokoll 
einhalten. . ; 55 

Es ist daher Aufgabe der Erfindung, em Verfahren zu 
schaffen, welches eine einfache, zeitsparende, sichere 
und die vorgenannten Probleme minimierende Pro- 
grammierung von unterschiedlichsten.Kfz-Steuergera- 
ten fur Busbetrieb erlaubt 60 

Diese Aufgabe wird durch ein gattungsgemaBes Ver- 
fahren mit den kennzeichnungsgemaBen Merkmalen 
des unabhangigen Patentanspruchs 1 gelost . 

Das erfindungsgemaBe Verfahren macht den bzw. die 
in einem Kfz-Steuergerat jeweils einzusetzenden Bus- 65 
Protokoll^Chip/s (CAN-Controller) fur den Program- 
mierer der jeweiligen Applikationssof tware unsicht- 
bar" Da der bzw. die Bus-Protokollchip/s gegenuber 



der Applikationssoftware also gewissermaBen "ver- \ 
deckt" wird/werden, spielt die Art des/der jeweils ver- 
wendeten Bus-Protokoll-Chip/s auch keine Rolle mehr. 

Diese Verdeckung wird dadurch geleistet, daB im Sin- 
ne einer Instruktions- und Kommunikationsoberfiache 
eirie universelle, von dem/den Bus-Protokollchip/s un- 
abhangige Schnittstelle definiert wird, zwecks Kopp- 
lung dieser Schnittstelle mit der/den Instruktions- und 
Kommunikationsoberflache/n des/der Bus-Protokoll- 
chip/s unabhangig von der Applikationssoftware ein auf 
den/die relevanten Bus-Protokollchip/s zugeschnittenes 
Treiber-Modul mit den Eigenschaften eines Adapters 
erzeugt wird, die steuergeratespezifische Applikations- 
software beziiglich der Buskommunikation ausschlieB- 
lich auf die genannte Schnittstelle abgestimmt und aus- 
gerichtet und insoweit unabhangig von dem/den Bus- 
Protokollchip/s erzeugt wird, die von dem/den Buspro- 
tokollchip/s unabhangige Applikationssoftware und das 
applikationsunabhangige Treiber-Modul mitteis eines 
Linkprozesses miteinander verkniipft werden und der 
so erhaltene Programmcbde im ROM des wenigstens 
einen Mikrorechners des SteuergerStes resident abge- 
legt wird. 

Die verknupfte Niederlegung des CAN-Controller- 
spezifischen Treiber-Moduls.zusammen mit der jeweili- 
gen Applikationssoftware in jedem einzelnen von einer 
Vielzahl von Steuergeraten erspart so nicht nur unnoti- 
ge Software-Entwicklungszeit fiir gleichartige oder 
ahnliche Kommunikationsschritte bzw. -operationen. 

Durch Reduktion der applikationsseitig auszufUhren- 
den Operationen auf nur wenige, einfache, jedoch lei- 
stungsfahige Routinen, die von der Applikation kom- 
mend auf den Bus gerichtet bzw. vom Bus kommend in 
die Applikation gerichtet auszufahren sind, kann auch 
eine sehr hohe Betriebssicherheit und Echtzeit-Vertrag- 
lichkeit vieler Steuergerate in einem CAN-Busnetzwerk 
erreicht werden, zumal entsprechende Treibermodule 
fur unterschiedliche Bus-Protokollchips bzw. CAN- 
Controller jeweils zentral entwickelt, ausgetestet und 
verfugbar gemacht werden konnen. 

Weitere Vorteile werden erschlossen, wenn das Trei- 
ber-Modul nach Lehre wenigstens eines der Ansprtiche 
2 bis 6 hergestelit wird. Werden z. B. gemaB Lehre des 
Anspruchs 4 wenigstens Netzwerk-Managementfunk- 
tionen in einem weiteren Modul zusammengefaBt und 
wird dieses weitere Modul analog dem Treiber-Modul 
der Applikationssoftware beigelinkt, kann der Program- 
mierer der Applikationssoftware von Aufrufen, Adres- 
sierungen und/oder Management-Alogorithmen befreit 
werden, die fur das Zusammenwirken im Netz des be- 
treffenden Kfz-Steuergerates mit anderen notwendig 
sind. Diese und weitere Vorteile, die sich bei Anwen- 
durig des erfindungsgemaBen Verfahrens erschlieBen 
lassen, werden im Zuge der nachfolgenden Beschrei- 
bung unter Bezugnahme auf die Zeichnung aufgezeigt 
Eszeigen: ; 

Fig. 1 ein Strukturschema zur Veranschauhchung der 
Einbettung des Treiber-Moduls zwischen Bus-Proto- 
kollchip und Applikationssof tware; 

Fig. 2 eine schematische Veranschauhchung der 
Adapterfunktion des Treiber-Moduls und seiner CAN- 
chip-spezifischen Austauschbarkeit; 

Fig. 3 eine schematische Veranschauhchung eines 
entsprechenden Treiber-Moduls zur Adaption dreier 
CAN-Chips an die Applikation; 

Fig. 4 eine schematische Veranschauhchung der Ab- 
arbeitung einer Sende-Warteschlange; 
Fig. 5 eine Veranschauhchung von Kopierfunktionen 
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des Treiber-Moduls; 

Fig. 6 eine schematische Veranschaulichung mehre- 
rer mit unterschiedlichen GAN-Chips ausgerusteter und 
zu einer virtuellen Einheit integrierter Steuergerate. 

Im folgenden wird unter dem Kurzbegriff des "CAN- 5 
Chip" immer der hardwaremaBig zu bestuckende Bus- 
Protokollchip verstanden. Ausdriicklich wird darauf 
hingewiesen, daB unter "dem" CAN-Chip auch mehrere 
entsprecbende Exemplare verstanden werden kdnnen, 
die gewissermaBen einen leistungsfahigeren CAN-Chip 10 
substituieren bzw. implementieren. Des weiteren wird 
unter "Applikation" die Abwicklung der Appiikations- 
software, d. h. der spezifischen Betriebs- und System- . 
software eines jeweils betrachteten Steuergerates auf 
seiner (Applikations-) Hardware verstanden, mit der 15 
Wirkung der erwunschten Steuerf unktiori. 
. GemaB Fig. 1 kommuniziert die Applikationssoftwa- 
re 11 nicht eigenstandig iiber den CAN-Chip 1 mit dem 
Bus 2. Bezugiich des Nachrichtenverkehrs mit letzterem 
stellt vieimehr das verfahrensgemaB herzustellende 20 
Treiber-Modul 10 einen inteliigenten Adapter dar, iiber 
den jeder kommunikative Zugriff auf den Bus 2 bzw. die 
Appiikationssoftware 11 zustande kommt Hieraus folgt 
eine entkoppelnde bzw. isolierende Funktiqn des Trei- 
ber-Moduls 10 zwischen CAN-Chip 1 bzw. Bus 2 und 25 
Appiikationssoftware 11. 

Die Herstellung der Appiikationssoftware kann in der 
Regel beim Hersteller bzw. Lief eranten eines Steuerge- 
rates geschehen. Die Herstellung des Treiber-Moduls 
kann beispielsweise durch den Fahrzeughersteller ge- 30 
schehen, der es dann Zulief eranten von busfahigen Steu- 
ergeraten zwecks Generation deren Software zur Ver- 
fiigung stellt. Auf diese Weise kann leicht sichergestellt 
werden, daB die Herstellung und Austestung des Trei- 
ber-Moduls mittels derselben Prufkriterien geschieht, 35 
die auch in Bus-Pruf systemen in Produktion und Service 
des Fahrzeugherstellers eingesetzt werden. Auf diese 
Weise werden systematische Softwareunvertraglichkei- 
ten ausgesehlossen und es konnen iokale Fehler und 
deren Ursache(n) leicht erkahnt werden. 40 

Zwischen Treiber-Modul 10 und Appiikationssoftwa- 
re i l kann noch ein separat zu erzeugendes Netzwerk- 
management-Mbdul 12 eingebunden werden.. Analog 
dazu kann des weiteren noch ein spezielles Kommuni- 
kations-Modul 13 erzeugt und zwischen Treiber-Modul 45 
10 und Appiikationssoftware 11 eingebunden werden., 
Jedenfalls verfugt die Applikation 11 aber immer uber 
einen freien Zugang 11' zum Treibermodul 10 iiber be- 
sagte CAN-Treiberschnittstelle 18. Unter bestimmten 
Voraussetzungen kann es in der Regel allerdings vor- 50 
teilhafter sein, Kommunikationsroutinen in die Appiika- 
tionssoftware 11 yon Anfang an einzubauen, wie dies 
z. B. der Veranschaulichung gemaB Fig. 6 zugrunde ge- 
legt ist 

Ein besonderes Netzwerkmanagement-Modul 12 55 
kann z. B. Aufgaben LZ. mit der Bedienung weiterer 
Steuergerate am Bus oder der Ermdglichiing eines Ein- 
draht-Notbetriebs erfullen, wenn z. B. eine von zwei 
elektrischen Busadern Masse- oder Versorgungsspan- 
nungsschluB hat. Ein besonderes Kommunikakations- 60 
Modul 13 kann z. B. diejenigen Teile von Kommunika- 
tionsroutinen zusammenfassen, die fiir mehrere Steuer- 
gerate identisch sind. Beispielsweise kann es applika- 
tionsspezifische Handler-Routinen, oder aber spezielle 
Kommununikatiohsfunktionen enthalten, etwa Kopier- 65 
funkdonen, wie z. B. die noch weiter unten erw&hnte 
Pre- und Postcopy-Funktion in Verbindung mit Elemen- . 
ten zur Empfangsfilterung. 



Es sind in der Art von Einhullenden eine erste Schnitt- 
stelle 17, namlich die Instruktions- und Kommunika- 
tionsoberflache des CAN-Chip, eine zweite Schnittstel- 
le, namlich die erfindungsgemaB zu definierende CAN- 
Treiber-Schnittstelle 18 und des weiteren noch eine Ma- 
nagement-Schnittstelle 19 und eine der Management- 
Schnittstelle 19 entsprechende und je nach Fiillung des 
Kommunikations-Moduls 13 zu spezifizierende Schnitt- 
stelle 19' der Applikation 1 1 kenntlich gemacht 

Funktionselemente des verfahrensgemaB zu erzeu- 
genden Treiber-Moduls werden aus Fig. 2 deutlich. 

Das Treiber-Modul 10A umfaBt il a., einen logischen 
Code 14. Dieser Code 14 ubersetzt gewissermaBen den 
CAN-Chip-typenspezifischen Instruktionscode von der 
Ebene der besagten ersten Schnittstelle 17 in ein stan- 
dardisiertes Instruktionsformat auf der Ebene der be- 
sagten CAN-Treiber-Schnittstellen 18, auf welcher die 
Appiikationssoftware 11 zugreift Der im ROM der Ap- 
plikation abgelegte logische Code 14 erfullt dabei eine 
Funktion vergleichbar der eines Adapters oder Interfa- 
ce auf die einfache, aber leistungsfahige Schnittstelle 18 
mit eigener funktionaler Intelligenz, die einerseits die 
Applikation — und damit den Applikationsprogram- 
mierer — von elementaren Kommunikationsaufgaben 
entlastet und andererseits die korrekte und netzweit 
einheitliche Programmierung des bzw. der CAN-Chips 
gewahrleistet 

Weiter umfaBt das Treiber-Modul 10 ein Datehfeld 
15, das entweder vollstandig oder iiberwiegend im ROM 
der Steuergeratehardware deponiert wird. Es ist dies 
wenigstens eine Initialisierungsstruktur und eine Kom- 
munikationsstruktur, Initialisierungsobjekte II ..... Iy 
bzw. Kommunikationsobjekten Kl ... . . Kx urhfassend. 

Dariiber hinaus beansprucht das Treiber-Modul 10A 
auBerdem noch einen (kleinen) RAM-Bereich, urn dort 
in einem fliichtigen Datenfeld 16 z. B. Statusinformatio- 
nen oder eine Warteschlange zu verwalten oder z. B. 
Funktionsriickgabewerte zu fuhren. 

Die Initialisierungsstruktur enthalt Daten, mit denen 
die Register bzw. Speicherzeilen des CAN-Chip in Ab- 
hangigkeit von der aktuell ausgewahlten Initialisie- 
rungsvariante geladen werden. 

Die Kommunikationsstruktur gliedert sich in Sende- 
und Empfangsstruktur, jeweils Sende- bzw. Emfangs- 
Kommunikationsobjekte umfassend. Die Sende- und 
Empfangsstrukturen enthalten Infonhationen iiber die 
zu sendenden bzw. zu empfangenden Daten sowie die 
erforderlichen Zeiger, welche die zu benutzenden Berei- 
che im RAM des Steuergerates bzw. CAN-Register 
festlegen. 

Fig. 2 veranschaulicht weiter, daB es fiir CAN-Chips 
1A, IB, 1C etc. jeweils eiii entsprechendes Treiber-Mo- 
dul 10 A, 10B, 10C ... gibt. Unterschiedlichen CAN- 
Chips 1A bis 1C, iiber End- und Empfangsstufeh 3 glei- 
chermaBen an den CAN-Bus 2 angeschaltet, sind also 
entsprechend unterschiedliche Treiber- Module 10 A bis 
10C zugeordnet. Entsprechend den unterschiedlichen 
Eigenschaften verschiedener CAN-Chips 10A . . . 10C 
variieren jeweils wenigstens der Code 14 und einzelnen 
Datenobjekte im Datenfeld 15 bei entsprechenden Trei- 
ber-Modulen. 

Im Sinne von Fig. 3 kann "der" CAN-Chip 1 auch aus 
mehreren realen Bus-Protokollbaust einen 1.1, 1.2, 1.3, 
eta bestehen, die insgesamt wie ein (einheitlicher) Chip 
zwischen Appiikationssoftware 11 und Bus 2 wirkeru 
Ohne Beschrankung der Ailgemeinsheit realisiert ein 
entsprechend aufgebautes Treiber-Modul 10' auch hier 
die Treiberschnittstelle 18 und "verbirgf dann eine ent- 
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sprechende Mehrzahl von CAN-Chips gegeniiber dem 
ProgrammiererderApplikationssoftware. 

Men Treiber-Modulen 10A, 10B IOC . gleich ist je- 
doch eine einheitliche Beschaff enheit der CAN-Treiber- 
schnittstelle 18, so daB der applikationsseitige Funk- s 
Saufruf des Treiber-Moduls stets mit derse ber > Da- 
tenobjekt-Referenz erfolgen kann, dh. unabhangig 

vombenutztenCAN-Chip. . . . 

Bei der Herstellung des Moduls wird der logische 
Treiber-Code beispielsweise insgesamt so gebaut daB 10 
er, in Verbindung mit den vorerwahnten Daten, nach 
der Verknupfung mit der Applikationssoftware folgen- 
de Funktionen leistet: 



a. Initialisierung 



15 



Vor dem Beginn einer Kommunikation werden die 
CAN-Kommunikationspfade und der CAN-Controller 
initialisiert Dies geschieht durch emfachen Aufruf der 

Funktion . 20 

InitfZeigerauflnitialisierungsobjekt). . 

Hierfur werden in dem als Argument des Imtialisie- 
rungsaufrufs bezogenen Iniualisierungsobjekt alle not- 
wenaigen Parameter fiir die CAN-protokollgemaBe 
Chipinitialisierung abgelegt 25 

b. Aussenden von Daten 

Fur die Aussendung von Daten wird ein Sende-Kom- 
munikationsobjekt definiert in dem unter anderein i ein 30 
die betreffende CAN-Nachricht kennzeichnender Iden- 
tifier und ein Zeiger auf die RAM-Adresse der auszu- 
sendenden Applikationsvariable abgelegt wird. Die 
Aussendung von Daten wird bewirkt durch emfachen 
Aufruf der Funktion . . 35 

Transmit(Zeiger auf Sende-Kommunikationsobjekt). 
Dieser Aufruf bewirkt, daB mittels des Kommuruka- 
tionsobjekts die relevante Applikationsvariable in den 
CAN-Chip oder in den Treiber (namlich z.B. m _eine 
Warteschlange, s. u.) kopiert wird. AnschheBend erfolgt 40 
deren Aussendung auf deh Bus vorzugsweise asynchroiu 
was bedeutet, daB die. Applikationssoftware mcht auf 
eine Quittung des . erf olgreichen AussendeyorgMges 
wartet Sie wird jedoch zu einem fruhestmbglichen Zeit- 
punkt dariiber informiert. Auch wird die erfolgreiche 45 
Obernahme der AppUkationsvariable in die Verantwor- 
tung des Treiber-Moduls der Applikation angezeigt 



Register, das zwecks Ladung als "Empfangsfenster 1 ge- V 
offnet wh-di sofern der Identifier einer CAN-Botschaft 
ki eine vorbestimmte Maske fallt Die Selektion bzw. 
AkzeptanzprOfung aus einer VielzaW von aus diesem 
Register holbaren Daten muB also auBerhalb eines sol- 
chen einf acheren CAN-Chips geschehen. . 
Vorzugsweise wird das Treiber-Modul so gebaut, daB 

es auch diese Funktion leistet, indem es den Empfangs- 
betrieb interniptgesteuert abwickelt Dazu wird fOr je- 
den zu empfangenden Nachrichtentyp em Empfangs- 
Kommunikationsobjekt definiert In diesem wird u£ 
der die betreffende CAN-Botschaft kennzeichnender 
Identifier und ein Zeiger auf die Zielyariable irn RAM 
der Applikation abgelegt Durch den emfachen Aufruf 
Receive (Zeiger auf Empfangs-Kommunikationsobjekt) 
werden die Empfangsdaten aus dem Empfangs-Buffer- 
register des CAN-Chip in einen fur relevante Empfangs- 
daten vorgesehenen Speicherplatz im RAM der Appli- 
kation (Zielvariable) kopiert Das Treiber-Modul dese- 
lektiert insoweit also alle unerwiinschten Empfangs- 
Kommunikationsobjekte. 

Auf diese Weise wird - unabhangig vom realen 
CAN-ProtokoUchip - z. B. die Funktion ernes komfort- 
ableren CAC-Chip, etwa eines FULLCAN-Chip, substi- 
tuiert, welcher aufgrund AusrUstung mit.emem eigenen 
RAM eine Akzeptanzliste fiir alle uberhaupt zu empfan- 
genden und in vorbestimmte RAM-Bereiche des Appli- 
kationskontroUers zu schreibenden Nachnchten halten 
und verwalten kann. 

Es wird ersichtlich, daB relevante Identifier nur dem 
Hersteller des Treiber-Moduls bekannt sem mussen und 
in der ROM-Liste 15 des Treiber-Moduls verzeichnet 
sind die Applikation bzw. der die Applikationssoftware 
herstellende Programmierer dieselben jedoch mcht zu 
kennen braucht weil Empfangsdaten, die weiterverar- 
beitet werden sollen, immer nur aus yorbestimmten, 
festliegenden Speicherzellen des Apphkations-RAMs 
abgeholt zu werden brauchen. 



c. Sendeabbruch 



50 



Zwecks Abbruch bzw. NichtausfQhrung eines bereits 
erfolgteri Aufrufs zum Versand einer Nachncht 1st die 
besondere Funktion 

Cancel (Zeiger auf Sehde-Kommunikationsobjekt) 
vorgesehen. Ihr Aufruf bewirkt die Stornierung eines 55 
vorlusgegangenen Transmit-Aufrufs durch Uschung 
des Sendfauf trages im Treiber oder - soweit bereite m 
das Sende-Bufferregister des CAN-Chip eingeschneben 
und noch nicht versandt — eben dort 

60 

d. Empfang 



Im Gegensatz zu komfortablen CAN-Chips mit eige- 
nem RAM (etwa FULLCAN-Chips) smd einfachere 
CAN-^s etwa BASICAN-Chips) nicht in der Lage 65 
alle Nachrichten, die Uberhaupt empfangen werden 
kdnnen oder sollen, vollstandig selbst zu filtern. _ 

Diese einfacheren CAN-Chips verfugen nur uber ein 



e. Precopy und Postcopy 

Urn einer Applikation beziiglich zu empfangender 
Daten die MSglichkeit einer Selektion zu bieten (z B. 
fiir Filterungs- und/oder OberprUfungsfunktionen), 
werden in dem verfahrensgemaB zu erzeugenden Trei- 
ber-Modul wenigstens zwei weitere Subroutine Pre- 
copy" und "Postcopy" eingebaut welche es der Applica- 
tion erlauben, unmittelbar vor dem Empfang von Daten 
bzw. unmittelbar nach dem Auslesen empfangener Da- 
ten aus dem Empfangs-Bufferregister 21 CAN-Chip 
1 in die Zielvariable (Zielspeicherplatz im RAM der Ap- 
plikation) EinfluB auf die empfangenen Daten zu nen- 
men. Wie diese beiden Funktionen wirken 1st in Fig. 5 
veranschaulicht 

Mit 21 ist das Empfangs-Bufferregister des am Bus 2 
liegenden CAN-Chip 1 bezeichnet in welches die Emp- 
fangsbotschaften vom Bus geladen werden. Mit 15 1st 
ein kleiner Ausschnitt aus dem ROM und mit 16 em 
kleiner Ausschnitt aus dem RAM der Applikation be- 
zeichnet Beispielsweise sind im ROM 15 Speicherberei- 
che 23.1, 23.2, 233, etc. vorgesehen, in welche Identitier, 
bier beispielsweise x, y, und 49, fQr Empfangsnachnch- 
ten eingeschrieben sind. Jedem Identifier smd^hier bei- 
spielsweise acht weitere Speicherplatze 23.1.1 bis 2J.1.B, 
23.2.1 bis 23^8, 233.1 bis 233.8, etc. zugeordnet, m 
welche zum jeweiligen Identifier gehbrende Parameter 
abgelegt sind. ,,__„- 
Im RAM 16 sind drei verschiedene Speicherplatze 25, 
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27 und 30 heryorgehoben, in welche eine Empfangsbot- 
schaft ablegbar ist Dabei ist angenommen, dafi der 
Speicherplatz 25 zur Ablage der Empfangsbotschaft 
. zwecks deren unmittelbarer Weiterverarbeitung, der 
Speicherplatz 27 zur Ablage der Empfangsbotschaft 
zwecks einer wie immer gearteten Bearbeitung vor 
Weiterverarbeitung, und der Speicherplatz 30 zur Abla- 
ge einer Kopie der Empfangsbotschaft nach deren Emp- 
fangseinschrieb in das RAM 16 vorgesehen ist 

Die Funktion ist folgende. Botschaften werden uber 
den Bus 2 im Broadcast- Verfahren versandt, erreicrien 
insoweit also grundsatzlich alle CAN-Chips der einzel- 
nen am Bus liegenden Steuergerate. Soweit es sich hier- 
bei nicht um CAN-Chips mit 100%iger Akzeptanz-Fil- 
terung, also beispielsweise FULLCAN-Chips, handelt, 
erfolgt wenigstens. die Filterung bzw. Diskrimination 
der Empf angsbotschaf ten vermittels des Treiber-Mo- 
duls auBerhalb des CAN-Chip 1. 

Sobald eine beliebige Botschaft im Empfangs-Buffer- 
register 21 eingeladen ist, greift die Applikation per In- 
terrupt-Service- Routine 22.0 auf das ROM 15 zu und 
% iiberpruft, beispielsweise durch sukzessives Abfragen 
22.1, 22.2 alle dort in Speicherplatzen 23.1, 23.2, 23.3, etc. 
abgelegten Identifier auf Obereinstimmung mit dem 
Identifier der Empfangsbotschaft ab. 

U.U. wird keine tioereinstimmung festgestellt, was 
bedeutet, daB die Empfangsbotschaft nicht ausgewertet 
wird, weil sie z. B. gar nicht fur das betrachtete Steuer- 
gerat aus einer bestimmten Kategorie von Steuergera- 
,ten, etwa solchen mit einem BASICAN-Chip, bestimmt 
ist. : ' 

Wird jedoch der in das Empfangs-Bufferregister aktu- 
ell eingeladene Empfangs-Identifier, hier angenommen 
"49", beispielsweise im Speicherplatz 23.3 vorgefunden, 
fragt die Interrupt- Service Routine alle nachfolgenden 
Speicherplatze 23.3.1 bis 23.3.8. sukzessive 22.3 nach 
darin enthaltenen Adress-Codierungen fur den RAM- 
Einschrieb besagter Empfangsbotschaft ab. Beispiels- 
weise ist in den Speicherplatz 233.1 eine "0" einge- 
schrieben. Dies bewirkt den Einschrieb 24 der Botschaft 
im Empfangs-Bufferregister 21 in den Speicherplatz 25 
im RAM 16 der Applikation, dessen Adresse z. B. im 
ROM-Plaiz 23.3.2 abgelegt ist Ist in den Speicherplatz 
23.3.1 hingegen ein von "0" abweichender Wert — hier 
beispielsweise "101 10" — eingeschrieben, so wird dieser 
Wert als Startadresse einer zwecks Bewertiing, Filte- 
rung, etc der Empfangsdaten vorgesehenen Anwender- 
funktion interpretiert, die mit dieser Adresse im Spei- 
cherplatz 27 des RAMs 16 der Applikation abgeiegt ist 
und der die Botschaft im Empfangs-Bufferregister 21 
unterworfen wird (Precopy), bevor sie weiterverarbei- 
tet (und zu diesem Zwecke dann z. B. in den Speicher- 
platz 25 abgelegt) wird. Hierzu konnte die Empfangs- 
botschaft z. B. voriibergehend in einen Zwischenspei- 
cherplatz 28 im RAM 16 geladen werden. Entsprechen- 
de Adressen der RAM-Speicherplatze 27 und 28 konnen 
im ROM-Speicherplatz 233,1 mitabgelegt sein. 
. Ein bestimmter Wert im letzten Speicherplatz 233.8 
bewirkt hingegen, daB die zwecks Empfangsverarbei- 
tung bereits ins RAM 16 eingeschriebene Empfangsbot- 
schaft in einen besonderen Speicherplatz 30 des RAMs 
.16 kopiert 29 wird (Postcopy), was z. B. fttr ein Steuerge- 
rat wichtig seiri kann, das die zeitliche Anderung einer 
MeBgrpBe auswertet und insoweit auf die Festhaltung 
: . jeweils wenigstens eines letzten bzw. zurfickliegenden 
MeBwertes angewiesen ist 

Es konnen so im Zuge des Datenempfangs gezielt 
kurze, applikationsspezifische Operationen bezQglich 



empfangener Daten ausgefiihrt werden, wie z. B. die 
Demultiplexierung eines CAN-Datenpakets in einzelne 
Variable, die Selektion bestimmter Bytes einer Nach- 
richt, Umlenkung. empfangener, aber fehlerhafter Da- 

5 ten, zusatzliche bzw. verscharfte Empfangsfilterung, In- 
terpretation oder Klassifikation oder Entschliisselung 
von Daten vor deren Abspeicherung, etc. 

ErsichtlichermaBen erschliefien diese zwei Routinen 
eine sehir differenzierte Ve'rarbeitbarkeit von Emp- 

io fangsbotschaften. Sie werden durch den einfachen Auf- 
ruf 

Precopy (Zeiger auf Empfangs-Kommunikationsobjekt) 
oder 

Postcopy (Zeiger auf Empfangs-Kommunikationsob- 
15 jekt) 
aktiviert 

f. Remote Request Service 

20 Das Treiber-Modul kann auch die Remote-Eigen- 
schaften des CAN-Protokolls unterstiitzen. Die entspre- 
chende Remote Request Service Funktion emuliert bei 
Anwendungen mit CAN-Chips, die keine automausche 
Beantwortung eines Remote Request unterstiitzen, die 

25 immanente Remote Request Funktion von CAN-Chips, 
die ohne Einschrankung das. gesamte CAN-Protokoll 
unterstiitzen und autonom abwickeln konnen, etwa 
i FULLCAN-Chips. Dabei kann die Transmit-Funktion 
vermittels eines im CAN-Protokoll designierten Steuer- 

30 Flags Remote-Botschaften auf den Bus aussenden. Emp- 
fangene Remote-Frames werden entweder durch den 
FULLCAN-Chip oder durch das Treiber-Modul bear- 
beitet und beantwortet Die Apphkationssoftware 11 
bzw. die Applikation wird hiervon uber eine entspre- 

35 chende Statusinformation unterrichtet, welche in dem 
schon erwahnten Datenfeld 16 abgelegt wird. 

Fur die Bearbeitung von schnell aufeinanderfolgen- 
den Sendeanforderungen und zur Realisierung einer 
Multitaskingfahigkeit des Treiber-Moduls ist es vorteil- 

40 haft in diesem gemaB Fig. 4 eine Sende-Warteschlange 
20 zu impjementieren. Deren Verwaltung und Abarbei- 
tung geschieht vorzugsweise asynchron und vom CAN- 
Chip aus interruptgesteuert Der Programmierer der 
Applikationssoftware ist dann auch beziiglich Versand- 

45 abfolgen ungebunden vom CAN-Chip und braucht ihri 
deshalb nicht zu kennen. 

Neben Anforderungen seitens der Applikation kon- 
nen in eine solche Warteschlange auch Sendeanforde- 
rungen eines besonderen Netzwerkrnanagement-Mo- 

50 duls 12 geladen werden, welches mehr oder weniger fest 
in die Applikationssoftware 11 eingebunden ist Die Ap- 
plikationssoftware wird jedenfalls durch kommunika- 
u'onsobjektbezogene Statusinformation, die in die Sta- 
tusdatei in das RAM 16 der Applikation geschrieben 

55 wird, uber den jeweiligen Zustand des Sendeauftrages 
'aktuell inf ormiert 

Die Sendewarteschlange bewirkt eine sehr vorteilhaf- . 
te zeitliche Entkopplung zwischen der Applikationssoft- 
ware, den CAN-Busverhaltnissen und einzelnen Tasks 

eo H« If 11.2, 113, etc. der Applikationssoftware unterein- 
ander. 

Da eine solche Warteschlange bezuglich eines aktuel- 
Ien Sendeaufrufs seitens der Applikationssoftware we- 
gen ihrer biisbelegungsabhangig asynchronen Abarbei- 
65 tung eine gewisse mittlere Mindestdurchsatzverzdge- 
rung fiir Sendeanforderungen involviert, ist fiir beson- 
ders dringende Botschaften eine Erweiterurig der 
Transmit-Funktion vorzusehen, namlich eine : 
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Ein bevorzugter Sofortversand eines Kommumka- 
tionsobjekts, welches in die Kommunikationswartescn- 
lanee geladen wurde, ist durch den einfachen Aur. rut 5 
TransmitFast (Zeiger auf Sende-Kommunikationsob- 

SSuch. Dieser Treiberaufruf bewirkt, daB das bezoge- 
ne Kommunikationsobjekt bei bereits wartenden Sen- 
deauftragen in den untersten Warteplatz in der War- io 
teschlange geschrieben und wartende Auftrage somit 
um einen Platz h6her geschoben werden, von wo aus 
das Kommunikationsobjekt somit mit dem nachsten in- 
terrupt sogleich in das Sende-Bufferregister des CAN- 
Chip transferiert wird. 15 

Die bereits erwahnte Sendeabbruchsfunktion 
Cancel (Zeiger auf Sende-Kommunikationsobjekt) 
bewirkt LZ. mit der Sendewarteschlange die ^Loschung 
eines in der Warteschlange oder bereits im Chip befind- 
lichen Sendeaufrufs mit der Wirkung, daB alle nach die- 20 
sem Aufruf in die Warteschlange emgeschnebenen Aut- 
trage in der Prioritat um eineri,Platz nach oben (bzw. 
nach unten in der in Fig. 4 gewahlten Symbc-ldarstellung 
der Warteschlange als FIFO-Register) rucken, von wo 
aus sie dann um einen Interrupt-Schritt fruher abgear- 25 
beitet werden. . ... Am 

Diese Funktion erlaubt also z. B„ erne bereits fur den 
Versand in die Warteschlange geladene Nachncht, die 
z B. wegen hoher Busbeiastung aber noch nicht ver- 
sandt werden konnte und deshalb schon unaktuell ge- 30 
worden ist und durch eine aktuellere ersetzt werden 
' sollte, unwirksam zu machen; mittels der TransmitFast- 
Funktion kann dann die aktuell verfugbare Nachncht 
bevorzugtversandt werden (Priority-Boost). 

ImTreiber-Modul konnen noch Standby-Funktionen 35 
realisiert werden, so z. B.: 



h. Power Down 

Mittels des Aufruf s 

PowerDownO . 
kann der CAN-Chip genereil bzw. in Abhangigkeit von 
einem Argument in den stromsparenden Standby-Mo- 
dus gebracht werden. 

i. Wake Up 



Die Funktion 

WakeUpO . 
wird vom Programmierer der AppUkationssoftware 50 
selbst geschrieben und vom Treiber-Modul nach l emem 
entsprechenden Wake-Up-Interrupt des CAN-Chip 

aU EsTsfinsoweit ersichtlich, daB das erfindungsgemaBe 
Verfahren der Programmcodeerzeugung zur Program- 55 
mierung des ROMs eines busfahigen, sich auf wemg- 
stens einen Mikrorechner stutzenden Kfz-Steuergera- 
tes zum einen zu einer erheblichen Straffung des Appli- 
kationsprogrammesund - sofern jeweus alle Steuerge- 
rate am Bus nur die zentral ausgetesteten Funktionen 6 o 
entsprechender Treiber-Module nutzen - zu emer Ef- 
fektivierungderKommunikationimNetzfOhrt 

Fig. 6 veranschaulicht noch, wie eine Vielzahl von 
verfahrensgemaB programmierten s ; euer ^ e ^ 
4B 4C, etc., die mit ganzlich verschiedenen CAN-Chips 6 5 
1 A IB 1C, etc. ausgerustet sein konnen, fiber den Bus 2 
miteinander gekoppelt werden; es ist hierbei der Son- 
derfall veranschaulicht, bei dem ein besonderes Kom- 



munikations-ivioaui 10 cnuam, ~: 7 \ 

den Routinen jeweils in der geratespezifischen Apphka- 
tionssoftware HA 1 tB, HQ etc. integriert smd 

Dabei stellen entsprechende Treiber-Module 10A, 
10B, 10C, etc. teils direkt, teils iiber Telle 12A, 12B, 12C, 
etc. einer iibergeordneten Netzwerkmanagement-Sort- 
ware die Verbindung unter den jeweihgen Apphka- 
tionsprogrammen HA, 11B, 11C, etc. in den verschiede- 
nen Steuergeraten 4A, 4B, 4C, etc. her. 

Es ist weiter ersichtlich, daB die schraf fiert angelegten 
Telle ein virtuell einheitliches Informationssystem, d. h. 
eine virtueUe Funktionseinheit, bilden, welche/s auf- 
grund der in alien Steuergeraten verteilt untergebrach- 
ten Netzwerkmanagement-Software sowohl in Rich- 
tung der jeweiligen AppUkationssoftware als a u ch in 
Richtung des Busses 2 identische Funktionalitat fur alle 
Steuergerate 4A, 4B, 4Q etc bietet, sofern diese nur mit 
CAN-Chips gleicher Protokollnutzungsbreite ausge- 

stattetsind. , c . 

Ferner ist ersichtUch, daB bei Verwendung des erfin- 
dungsgemaBen Verfahrens zur Programmierung busfa- 
higer elektronischer Steuergerate in emem Kraftfahr- 
zeug sowohl fur die Herstellung als auch das [ Austesten 
unterschiedlichster AppUkationssoftware llA, HB, lie, 
etc. fur die einzelnen Steuergerate 4A, 4B, 4C, etc. - 
unabhangig von dem bzw. den geratespezifisch emge- 
setztenCAN-Chip/s - identische Bedingungen vorgeb- 
bar und nutzbar sind, woraus erhebhche Zeit- und K.o- 
steneinsparungen und Sicherheitsgewinne resultieren. 

SchUeBUch ist ersichtUch, daB sich im Zuge der An- 
wendung des erfindungsgemaB fortgebildeten Verfah- 
rens die Realisierung des in Fig. 6 veranschauhchten 
Informationsubertragungssystems im Smne einer virtu- 
ellen Einheit praktisch von selbst ergibt Das Informa- 
tionsubertragungssystem wird von jien schraffierten 
Teilen gebildet. Hierfur werden also Netzwerkmanage- 
ment-Module 12A, 12B, *2C etcjorgesehen, die ^einer- 
seits mit den jeweiligen Treiber-Modulen 10A, 10B, 10C, 
etc. und andererseits iiber ebenfalls einheithche Kom- 
munikations-SchnittsteUen 19A, 19B 19C etcx mit der 
jeweiligen AppUkationssoftware HA, HB, 11U etc. 
kommunikationsfahig sind. 

In der Praxis ergibt sich diese Wirkstruktur durch 
einf aches Beilinken von in anaioger Weise zentral aus- 
getesteten Netzwerkmanagement-Modulen 12A, i^iJ, 
oder 12C zusammen mit dem jeweils CAN-Chip-speziti- 
schen Treiber-Modul 10A, 10B oder 10C zur jeweihgen 
AppUkationssoftware HA, HB, 11C in emer Netzwerk- 
fehler somit weitgehend ausschUeBenden Weise. 



40 
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PatentansprUche 

1 Verfahren zur Programmierung eines busfahigen 
elektronischen Kfz-Steuergerates, welches zur 
Realisierung seiner Steuerfunktion mit wemgstens 
einem Mikrorechner (und) mit ROM und RAM zur 
Aufnahme bzw. Abwicklung der fur die Steuer- . 
funktion erforderUchen AppUkationssoftware und 
des weiteren mit wenigstens einem Bus-Protokoll- 
chip ausgerustet ist, und wobei die Programmie- 
rung des ROMs in einer Weise geschieht, daB be- 
sagte AppUkationssoftware Ober den wenigstens 
einen Bus-Protokollchip und insoweit — im Sinne 
einer (jeweils) ersten SchnittsteUe - tiber dessen/ 
deren spezifische Instruktions- und Kommunika- 
tionsoberflache/n mit dem Bus kommuniziert, da- 
durch gekennzeichnet 

— daB eine zweite, von dem wenigstens einen 
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Bus-ProtokoHchip (1; 1.1, 1.2, 13) unabhangige 
Schnittstelle (18) im Sinne einer weiteren, uni- 
versellen Instruktions- und Kommunikations- 
oberflache definiert wird; 

— daB zwecks Kopplung besagter erster und 5 
zweiter Schnittstellen (17 und 18) unabhangig 
von der Applikationssoftware (11) ein auf den 
wenigstens relevanten Bus-Pro tokollchip (1; 
1.1, 1.2, 13; 1A, IB, 1C) zugeschnittenes Trei- 
ber-Modul (10; 10'; 10A, 10B, 10C) rnit den 10 
Eigenschaf ten eines Adapters erzeugt wird ; 

— daB bezuglich der Buskommunikation die 
steuergeratespezifische Applikationssoftware 
(11) ausschlieBlich auf diese zweite universelle 
Schnittstelle (18) abgestimmt und ausgerichtet 15 
und insoweit unabhangig von dem wenigstens 
einen Bus-Protokollchip erzeugt wird; 

— daB die vom Bus-Protokollchip (1; 1.1, 1.2, 
13; 1A, IB, 1C) unabhangige Applikationssoft- 
ware (11) und das applikationsunabhangige 20 
Treiber-Modul (10; lOA^ 10B, 10C) mittels ei- 
nes 'Linkprozesses miteinander verknupft wer- 
den, und 

— daB der als Ergebnis des Linkprozesses er- 
haltene Programmcode in besagtem ROM re- 25 

. sident abgelegt wird. 

2. Verfahren gemaB Anspruch 1, dadurch gekenn- 
zeichnet, 

— daB das Treiber-Modul (10; 10'; 10A, 10B, 
10C) in der Weise hergestellt wird, daB es nach 30 
der VerknOpfung mit der Applikationssoftwa- 
re (11) wenigstens folgende Funktionen leistet: 

— die Initialisierung der Bus-Kommuni- 
kationspfade und/oder des wenigstens ei- 
nen Bus-Protokollchip (1; 1.1, 1.2, 1.3) vor 35 
dem Beginn einer Komraunikation; 

— die Abholung von Sendedaten unter 
wenigstens einer RAM-Adresse, deren 
Ladung in ein Senderegister des wenig- 
stens einen Bus-Protokollchip und die 40 
Veraniassung des Auslesens der Sendeda- 
ten auf den Bus; 

— die Abholung von Ernpfangsdaten aus 
einem Empfangsregister (21) des wenig- 
stens einen Bus-Protokollchip (1; 1.1, 1.2, 45 
13) und deren Ladung in wenigstens ei- 
nen vorbestimniten Speicherplatz (25) im 
RAM des Mikrorechners. 

3. Verfahren gemaB Anspruch 2, dadurch gekenn- 
zeichnet, . 50 

— daB das Treiber-Modul (10; 10'; 10A, 10B, 
10C) in der Weise hergestellt wird, daB es nach 
der VerknOpfung mit der Applikationssoftwa- 
re (11) wenigstens folgende weitere Funktio- 
nen leistet: ' 55 

— den Aufbau und die Verwaltung einer 
Warteschlange (20) fur Sende-Kommuni- 
kationsobjekte; 

— den bevorzugten Versand von Sende- 
Kommunikationsobjekten aus der War- 60 
teschlange (20) unter Zuweisung der je- 
weils obersten Prioritat; 

— die iridividuelle, selektive Unwirksam- 
machung von Sende-Auftragen, bevor de- 
ren Versand erfolgt ist 65 

4. Verfahren gemaB Anspruch 1, dadurch gekenn- 
zeichnet 

— daB unabhangig von der Applikationssoft- 
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ware (1 1) und unabhangig von dem wenigstens 
einen Bus-Protokollchip (1; 1.1, 1.2, 13) noch 
wenigstens ein weiteres Modul (12, 13), bei- 
spielsweise ein Netzwerkmanagement- Modul 
(NWM; 12), hergestellt wird, und 

— daB das wenigstens eine weitere Modul (12, 
13) mit der Applikationssoftware (11) und/ 
oder dem Treiber-Modul (10; 10'; 10A, 10B, 
IOC) mittels eines Linkprozesses miteinander 
verknupft werden, um den im ROM des Steu- 
ergerates ablegbaren Programmcode zu er- 
halten. 

5. Verfahren gemaB Anspruch 2, dadurch gekenn- 
zeichnet, 

— daB das Treiber-Modul (10; 10'; 10A, 10B, 
10C) in der Weise hergestellt wird, daB es nach 
der Verknupfung.mit der Applikationssoftwa- 
re (11) wenigstens folgende weitere Funktion 
leistet: 

— die Unterwerfung der Ernpfangsdaten 
aus einem Empfangsregister (21) des we- 
nigstens einen Bus-Protokollchip (1; 1.1, 
1.2, 13) einer Bearbeitungsfunktion und 
die Ladung der so bearbeiteten Ernp- 
fangsdaten in wenigstens einen vorbe- 
stimmten Speicherplatz im RAM (16) des 
Mikrorechners des Kfz-Steuergerates. 

6. Verfahren gemaB Anspruch 2, dadurch gekenn- 
zeichnet, 

— daB das Treiber-Modul (10; 10'; 10A, 10B, 
10C) in der Weise hergestellt wird, daB es nach 
der VerknOpfung mit der Applikationssoftwa- 

• re (11) wenigstens folgende weitere Funktion 
leistet: 

— die Versetzung des wenigstens einen 
Bus-Protokollchip in einen stromsparen- 
den Standby- Modus. 
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